home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / pdox693.zip / TI124.ASC < prev    next >
Text File  |  1992-08-21  |  11KB  |  331 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.   PRODUCT  :  Paradox                                NUMBER  :  124
  9.   VERSION  :  All
  10.        OS  :  DOS
  11.      DATE  :  August 21, 1992                          PAGE  :  1/5
  12.  
  13.     TITLE  :  Explanation of Normalized and Non-Normalized Tables
  14.  
  15.  
  16.  
  17.  
  18.   This information sheet is a brief overview of normalization.  It
  19.   is by no means a complete discussion of this topic but does
  20.   contain the basic concepts and how they relate to Paradox.
  21.  
  22.   Normalization is a method of organizing information into discrete
  23.   flexible modules, where each record has the least number of
  24.   fields necessary to establish a unique identity for the record's
  25.   information.  Non-normalized structures, on the other hand,
  26.   provide as much information (therefore as many different fields)
  27.   as possible for each individual record.  Although normalization
  28.   is not required when creating Paradox table, it will, in general,
  29.   make it easier to manipulate your data.
  30.  
  31.   A normalized table is usually easier to analyze and query because
  32.   many similar values may be examined in a single field.  In
  33.   addition it is relatively easy to de-normalize a normalized table
  34.   through queries or 'crosstabs'.  The opposite is not true.
  35.  
  36.   The normalization process is typically broken up into three
  37.   stages or "forms".  The first normal form requires the removal of
  38.   all identical records (keying a table in Paradox performs this
  39.   function), and the removal of repeating groups.
  40.  
  41.   This is a simple example of a non-normalized table.  Note that
  42.   the different tool fields are actually repeating groups of
  43.   quantities:
  44.  
  45.   Orders═╦═Order #═╦═Hammers ╦═Screwdrivers═╦═Saws═╗
  46.          ║  0001   ║   3     ║      7       ║   0  ║
  47.          ║  0002   ║   0     ║      0       ║   0  ║
  48.          ║  0003   ║   0     ║      0       ║  14  ║
  49.          ║  0005   ║   5     ║      0       ║   0  ║
  50.  
  51.  
  52.   This example is keyed only on Order # with the quantities for
  53.   each tool in its own separate field.  If you had over a hundred
  54.   different tools to track it would be a laborious task to locate
  55.   each field when entering an order.  As you can see, this table
  56.   could be very difficult to manage.  The table would be quite
  57.   unwieldy even if it only contained a few orders.  In addition,
  58.   queries on this table would be significantly more difficult to
  59.   design.  Reports and forms will also be far more complex than the
  60.   normalized example below.  Using calculated fields may not even
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.   PRODUCT  :  Paradox                                NUMBER  :  124
  75.   VERSION  :  All
  76.        OS  :  DOS
  77.      DATE  :  August 21, 1992                          PAGE  :  2/5
  78.  
  79.     TITLE  :  Explanation of Normalized and Non-Normalized Tables
  80.  
  81.  
  82.  
  83.  
  84.   be possible, in some cases, if your calculation must be longer
  85.   than 175 characters.
  86.  
  87.   This is a normalized version of the Orders table in the first
  88.   normal form:
  89.  
  90.   Orders═╦═Order #═╦══Item #═╦ Quantity═╦═════Tool════╗
  91.          ║  0001   ║    1    ║    3     ║ Hammer      ║
  92.          ║  0001   ║    2    ║    7     ║ Screwdriver ║
  93.          ║  0002   ║    1    ║    1     ║ Clipper     ║
  94.          ║  0003   ║    1    ║   14     ║ Saw         ║
  95.          ║  0004   ║    1    ║    5     ║ Hammer      ║
  96.  
  97.  
  98.   This example table is keyed on both Order Number and Item Number
  99.   so that each Order may have more than one item.  Rather than have
  100.   a single record for each order with a separate field for each
  101.   tool that a customer could purchase, there is a separate record
  102.   for each tool purchase.  The separate tool fields are now
  103.   condensed into two fields: Quantity and Tool.
  104.  
  105.   The second normal form involves tables that have more than one
  106.   key field.  If a non-key field relies only part of the total key,
  107.   it should be moved to a separate table.  This means every field
  108.   in the table must be directly related to all of the key fields
  109.   not just some of them.
  110.  
  111.   The next example is a variation on the Orders table above.  The
  112.   table below is keyed on both Order # and Tool ID #:
  113.  
  114.   Orders═╦═Order #═╦══Tool ID #═╦════Tool Description════╗
  115.          ║  0001   ║    1       ║ Screwdriver            ║
  116.          ║  0002   ║    2       ║ Clipper                ║
  117.          ║  0003   ║    3       ║ Saw                    ║
  118.          ║  0004   ║    2       ║ Clipper                ║
  119.  
  120.  
  121.   This table violates the second normal form.  The Tool Description
  122.   field is only dependent on the Tool ID # field not the entire
  123.   composite key (Order # and Tool ID #).  To conform to the second
  124.   normal form the Tools Description information must be removed
  125.   from the Orders table and placed in a separate tools table with
  126.   its corresponding ID #.  Here is the correct version:
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.   PRODUCT  :  Paradox                                NUMBER  :  124
  141.   VERSION  :  All
  142.        OS  :  DOS
  143.      DATE  :  August 21, 1992                          PAGE  :  3/5
  144.  
  145.     TITLE  :  Explanation of Normalized and Non-Normalized Tables
  146.  
  147.  
  148.  
  149.  
  150.   Orders═╦═Order #═╦══Tool ID #═╗
  151.          ║  0001   ║    1       ║
  152.          ║  0002   ║    2       ║
  153.          ║  0003   ║    3       ║
  154.          ║  0004   ║    2       ║
  155.  
  156.   Tools═╦══Tool ID #═╦════Tool Description════╗
  157.         ║    1       ║ Screwdriver            ║
  158.         ║    2       ║ Clipper                ║
  159.         ║    3       ║ Saw                    ║
  160.         ║    4       ║ Hammer                 ║
  161.  
  162.  
  163.   This structure reduces redundancy of data in your tables.  The
  164.   description information need only be entered once in the Tools
  165.   table.  The orders table refers to the tools by ID # alone.
  166.  
  167.   The Third Normal Form requires the table be in second normal form
  168.   and that each field has a direct and permanent relationship to
  169.   the entire key.  If a non-key field is not always related to the
  170.   key it should be removed and placed in a new table.  Another way
  171.   of analyzing whether a field is related to the primary key is to
  172.   look for a direct relationship with non-key field.  In other
  173.   words: does this non-key field relate exclusively to another
  174.   non-key field in the table.
  175.  
  176.   The next section discusses the use of the Third Normal Form on
  177.   the Tools table.  In this case the table is still keyed on Tool
  178.   ID #.
  179.  
  180.   Tools═╦═Tool ID #═╦═Tool Descr══╦══Vendor═══╦═══Address════╗
  181.         ║   1       ║ Screwdriver ║ Acme Co.  ║ 123 Main St  ║
  182.         ║   2       ║ Clipper     ║ Tools R Us║ 456 2nd Ave  ║
  183.         ║   3       ║ Saw         ║ Acme Co.  ║ 123 Main St. ║
  184.         ║   4       ║ Hammer      ║ ABC Tool  ║ 900 Hammer Wy║
  185.  
  186.   This table violates the third normal form.  The Vendor and
  187.   Address are not always related to the key field in the table,
  188.   Tool ID #.  Consider what would happen if every tool a vendor
  189.   distributes were removed from the Tools table.  All information
  190.   on that vendor would be lost.  For example, if every entry for
  191.   Hammer were removed from the table, the database would lose the
  192.   name and address for ABC Tool.  This characteristic is known as a
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.   PRODUCT  :  Paradox                                NUMBER  :  124
  207.   VERSION  :  All
  208.        OS  :  DOS
  209.      DATE  :  August 21, 1992                          PAGE  :  4/5
  210.  
  211.     TITLE  :  Explanation of Normalized and Non-Normalized Tables
  212.  
  213.  
  214.  
  215.  
  216.   Delete Anomaly.  Although, this may be a business policy, it is
  217.   not a recommended practice in database design.
  218.  
  219.   A table that is not in third normal form also has a
  220.   characteristic known as an Update Anomaly.  For example, if Acme
  221.   Co. changed its address, every Address entry for Acme Co. would
  222.   have to be changed.
  223.  
  224.   If we use the criteria described previously to analyze the
  225.   relationship of the fields (i.e. do any of these fields relate
  226.   exclusively to another non-key field) we can easily identify the
  227.   offending fields.  Note that the Address field only relates to
  228.   the Vendor field and has no relationship to the key field Tool ID
  229.   #.  The following tables demonstrate the correct relationship
  230.   between tools and vendors according to the rules of the third
  231.   normal form.  Vendors are placed into a separate table, and keyed
  232.   on Vendor #.  Vendor number is a field created to simplify
  233.   identification and linking between the two tables.
  234.  
  235.   Tools═╦═Tool ID #═╦═Tool Description═╦══Vendor #══╗
  236.         ║   1       ║ Screwdriver      ║    1       ║
  237.         ║   2       ║ Clipper          ║    2       ║
  238.         ║   3       ║ Saw              ║    1       ║
  239.         ║   4       ║ Hammer           ║    3       ║
  240.  
  241.   Vendors═╦═Vendor #═╦═ Name═════╦══Address═════╗
  242.           ║   1      ║ Acme Co.  ║ 123 Main St  ║
  243.           ║   2      ║ Tools R Us║ 456 2nd Ave  ║
  244.           ║   3      ║ ABC Tool  ║ 900 Hammer Wy║
  245.  
  246.   In third normal form, the entries for Screwdriver and Saw can be
  247.   eliminated and the information for Acme Co. remains intact in the
  248.   Vendor table.  Also, information on Acme Co. must only be changed
  249.   once in the Vendors table to have a global effect on related
  250.   tables.
  251.  
  252.   In conclusion, the full normalization process will give us
  253.   compact, simple tables with a minimum of redundant data.  If
  254.   necessary there may be several of these compact tables linked on
  255.   common fields.  These tables may be accessed simultaneously in
  256.   Paradox through multi-table queries, forms, and reports.
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.   PRODUCT  :  Paradox                                NUMBER  :  124
  273.   VERSION  :  All
  274.        OS  :  DOS
  275.      DATE  :  August 21, 1992                          PAGE  :  5/5
  276.  
  277.     TITLE  :  Explanation of Normalized and Non-Normalized Tables
  278.  
  279.  
  280.  
  281.  
  282.   Bibliography of books on Normalization and general database
  283.   theory:
  284.  
  285.   1. Fabian Pascal, "SQL and Relational Basics", M&T Publishing
  286.      Inc. (1990)
  287.  
  288.   2. C.J. Date, "An Introduction To Database Systems - Volume I",
  289.      5th ed., Addison-Wesley Publishing Company (1990)
  290.  
  291.   3. C.J. Date, "An Introduction To Database Systems - Volume II",
  292.      2nd ed., Addison-Wesley Publishing Company (1985)
  293.  
  294.   4. C.J. Date, "Relational Database -- Selected Writings",
  295.      Addison-Wesley Publishing Company (1986)
  296.  
  297.   5. C.J. Date, "Relational Database - Writings 1985-1989",
  298.      Addison-Wesley Publishing Company (1990)
  299.  
  300.   6. E.F. Codd, "The Relational Model for Database Management:
  301.      Version 2", Addison-Wesley Publishing (1990)
  302.  
  303.   7. G.M. Nijssen, "Conceptual Schema and Relational Database
  304.      Design - A fact oriented approach", Prentice Hall (1989)
  305.  
  306.   8. Steve Reeves, "Logic For Computer Science", Addison-Wesley
  307.      Publishing (1990)
  308.  
  309.   DISCLAIMER: You have the right to use this technical information
  310.   subject to the terms of the No-Nonsense License Statement that
  311.   you received with the Borland product to which this information
  312.   pertains.
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.